在模型愈來愈強大的今天，我們似乎不再需要撰寫大量細節 prompt，一步一步指引 AI agent 完成開發。

可是，當軟體規模持續成長，真正需要被重視的，反而是如何讓 AI 參與的開發流程，持續而穩定地產出。

在開始大量使用 AI agent 之後，我慢慢把日常重複的工作整理成 skill。

一開始，我利用 OpenSpec 協助產生規格。但純文字 Markdown 很快就變得難以閱讀，後來又發現了另一個基於 OpenSpec 的工具：Spectra。

在開發的每個階段，似乎都可以找到適合的 skill 來使用。不過，實際開發時，我們通常還會搭配 Trello、Jira、Redmine 等專案管理工具。

於是，問題又出現了。

在開發的不同階段，我們必須把 AI 的產出重新整理，再更新回不同的管理系統。工程師的惰性這時候就出現了：

既然這些事情都在重複，為什麼不乾脆全部自動化？

第一個直覺的想法就是：

叫 AI 把整個流程整理成一組 skill，不就好了？

於是，第一版的 workflow 誕生了。

它可以從專案管理工具中找出待規劃的卡片，接著依序進行規劃、開發、code review 與 testing，並在每個階段更新卡片狀態。

當然，懶要更懶。

最後，我又利用 /loop，讓 agent 定期檢查 Trello card 的狀態，並把事件記錄到 DuckDB。系統找出卡片狀態的變動後，就啟動規劃、開發、review、testing 等不同的開發步驟。

一開始，這套流程真的很好用。

為什麼一開始很好用？

那時候我以為，這就是讓 AI 開發穩定化的方法。

第一，它替我記住了流程。

人很容易漏掉步驟，尤其是同時處理很多卡片時。skill 像一份會被自動執行的 checklist，讓流程不再只存在我的腦中。

第二，它降低了啟動成本。

我不需要每次都重新解釋「該怎麼做」。只要把卡片放到正確的位置，pipeline 就知道下一步大概該往哪裡走。

第三，它讓工作狀態變得可見。

卡片在不同欄位之間移動，代表工作從 Ready、In Progress、Review 到 Done。至少在表面上，我可以知道每張卡目前走到哪一步。

第四，它讓 AI 有了邊界。

我不再只對 Claude 說「幫我完成這張卡」，而是提供一個比較明確的工作環境：要讀哪些資料、要產出什麼、哪些檢查必須通過、什麼情況要停下來。

失控不是突然發生的

問題是，每次流程出錯，我採取的修正方式都很直覺：

在 skill 裡再加一條規則。

某次 branch 沒有正確建立，就補一段 branch 檢查。

某次卡片狀態和實際進度不同，就補一段狀態同步。

某次 review 失敗後流程沒有回到正確位置，就補一段例外處理。

某次 agent 重複處理同一張卡，就加上「同一張卡同時只能有一個 worker」的規則。

每一條規則單獨看都很合理，而且確實能解決眼前的事故。

但問題也慢慢累積了。

規則散落在不同的 SKILL.md、腳本、卡片欄位與人的記憶裡。流程的真正順序沒有一個明確來源，哪些是必要條件、哪些是例外處理、哪些是人工決定，也逐漸混在一起。

最後，這條 pipeline 變得很像一篇不斷加長的散文。

它看起來記錄了很多經驗，卻越來越難回答幾個基本問題：

• 現在系統到底處於什麼狀態？
• 哪個系統擁有這個事實？
• 這個動作失敗後，應該重試、回復，還是停止？
• 哪些規則可以用程式驗證？
• 哪些判斷真的需要交給模型？

最痛的一次重構

後來我做了一次沒有測試保護的 AI 重構。

原本只是想整理流程，結果一路產生了大約四十個修正 commit，經過十二輪 review，才勉強把行為拉回來。

這次事故讓我看見一件事：

問題不只是 AI 寫錯程式。

AI 其實只是忠實地執行了我提供給它的局部規則。真正的問題是，我沒有把整條流程描述成一個可以被檢查的模型。

真正的問題不是 AI 不夠聰明

我把流程當成文字文件，而不是一個 domain。

一句「完成後移到 Review」，其實隱藏了很多沒有寫出來的問題：

• 誰負責移動？
• 什麼叫完成？
• 測試失敗時還能不能移動？
• 移動成功但 branch 建立失敗時怎麼辦？
• 這個事件要不要留下紀錄？
• 之後的 worker 能不能重新接手？

文字可以描述這些事情，卻不會自動幫我檢查它們是否互相矛盾。

如果流程本身沒有清楚的狀態、事件與邊界，再強的模型也只是在更快地執行一套混亂的規則。

這個系列接下來要處理什麼？

接下來的三十天，我想做的不是再寫更多 prompt，也不是再增加更多規則。

我想把這條開發流程重新當成一個產品來設計：

• 用 DDD 與 EventStorming 找出真正的 command、event、aggregate 和 policy。
• 把 pipeline 從散文搬進資料，讓它有明確的 schema。
• 用 reducer 與 golden test 保護決定性流程。
• 用 Clean Architecture 把 Trello、GitHub 與模型隔離開來。
• 用 event-driven workflow 取代只能不斷輪詢的執行方式。
• 重新設計 reflection，讓反省真的能影響下一次行為。

這不是一個「AI 變聰明之後就會自動解決」的問題。

我真正想處理的是：如何讓 AI agent 不只會完成一次任務，而是能在一條清楚、可驗證、可以持續演進的工程流程裡工作。

我原本以為

只要把好的開發習慣寫成 skill，agent 就會穩定執行。

實際上

skill 只能記住當下的理解。

如果沒有 domain model、可驗證的狀態與測試保護，每一次事故都只會變成下一條規則，最後讓整條流程變成一篇沒有人敢修改的散文。